feat(invitations): claim invite token at open signup when userFacing is on - #3982

Summary

• What changed: when invitations.userFacing is true, the signup flow now claims and finalizes a presented invite token even while public signup is open — invitation.accepted, the analytics redemption event, referral reward, and referrer notification fire exactly as in closed-signup mode. userFacing: false (the default) keeps today's behavior unchanged, byte-for-byte. Also exposes invitations.userFacing in GET /api/auth/config (same top-level, unauthenticated pattern as sign.up) so a consumer can gate referral UI on it. The eligibility checker (the only code that calls claim()) now relays a claimed boolean on its opaque result so auth.controller.js trusts a single source of truth instead of re-deriving the same condition from config on both sides.
• Why: the open-signup gate resolved a presented invite token but never claimed/finalized it while public signup was open, so on open-signup deployments the referral loop could never convert — invitations went out, rewards never landed.
• Related issues: Closes ✨ Invitations: claim invite token at signup when userFacing, even with open signup + expose flag in auth config #3981

Scope

• Module(s) impacted: auth (signup controller, eligibility JSDoc), invitations (eligibility checker, config comment, README)
• Cross-module impact: none (the existing generic registerSignupEligibility seam — auth still never imports invitation code)
• Risk level: low (change is behind an existing config flag defaulting to false; default-path behavior is unchanged, covered by a byte-for-byte regression test)

Validation

• npm run lint
• npm test (npm run test:unit — 2245 tests, npm run test:integration — 499 tests, npm run test:e2e — 16 tests, all green)
• Manual checks done (if applicable) — full unit + integration matrix for {userFacing on/off} × {signup open/closed} × {token valid/absent/foreign-email}, plus a real-DB end-to-end pass proving single-use, referredBy, and the invitation.accepted event all fire in the new cell

Guardrails check

• No secrets or credentials introduced (.env*, secrets/**, keys, tokens)
• No risky rename/move of core stack paths
• Changes remain merge-friendly for downstream projects
• Tests added or updated when behavior changed

Notes for reviewers

• Security considerations: all existing token guards stay enforced unconditionally (email pin, single-use via the atomic claim CAS, expiry, the create()-time self-referral guard) — this PR only widens WHEN the existing claim/finalize path runs, never how it validates a token. A signup without a token never invents attribution in either flag state.
• Mergeability considerations: none — additive, config-gated, default-off behavior change plus a passthrough config exposure.
• Follow-up tasks (optional):
  • The OAuth signup path's eligibility check is still skipped entirely while public signup is open (unrelated to this issue, which scoped to the token-based local-signup path only — no OAuth invite exists in that state today to claim).
  • 🐛 signup analytics invited:true doesn't distinguish presented-vs-attributed invites #3983: the user_signed_up analytics event's invited/invitationId/invitedBy fields key off a resolved invite, not off actual attribution (eligibility.claimed) — a narrow, pre-existing gap this PR's own claim-race downgrade slightly widens (found in independent review, filed rather than expanding this PR's scope).